System and Method for Sharing a SIP Communication Service Identifier

ABSTRACT

A method for providing a user agent (UA) with service identification data. The method includes an application server (AS) transmitting Session Initiation Protocol (SIP) data. The SIP data comprises an identifier of the AS and a service identifier for at least one service supported by the AS. The method further includes the UA receiving the SIP data.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication No. 60/971,495, filed Sep. 11, 2007, by John-Luc Bakker, etal, entitled “System and Method for Identifying a SIP CommunicationService Identifier” (32769-US-PRV-4214-03500), which is incorporated byreference herein as if reproduced in its entirety.

BACKGROUND

The IP (Internet Protocol) Multimedia Subsystem (IMS) is a standardizedarchitecture for providing multimedia services and voice-over-IP callsto both mobile and fixed user agents (UAs). The Session InitiationProtocol (SIP) been standardized and governed primarily by the InternetEngineering Task Force (IETF) as a protocol for setting up and managingIMS-based calls. As used herein, the terms “user agent” and “UA” mightin some cases refer to mobile devices such as mobile telephones,personal digital assistants, handheld or laptop computers, and similardevices that have telecommunications capabilities. Such a UA mightconsist of a UA and its associated removable memory module, such as butnot limited to a Universal Integrated Circuit Card (UICC) that includesa Subscriber Identity Module (SIM) application, a Universal SubscriberIdentity Module (USIM) application, or a Removable User Identity Module(R-UIM) application. Alternatively, such a UA might consist of thedevice itself without such a module. In other cases, the term “UA” mightrefer to devices that have similar capabilities but that are nottransportable, such as fixed line telephones, desktop computers, set-topboxes, or network nodes. When a UA is a network node, the network nodecould act on behalf of another function such as a UA or a fixed linedevice and simulate or emulate the UA or fixed line device. For example,for some UAs, the IMS SIP client that would typically reside on thedevice actually resides in the network and relays SIP messageinformation to the device using optimized protocols. In other words,some functions that were traditionally carried out by a UA can bedistributed in the form of a remote UA, where the remote UA representsthe UA in the network. The term “UA” can also refer to any hardware orsoftware component that can terminate a communication session that couldinclude, but is not limited to, a SIP session. Also, the terms “useragent”, “UA”, “user equipment”, “UE”, and “node” might be usedsynonymously herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a block diagram of a telecommunications system according to anembodiment of the disclosure.

FIG. 2 is a diagram of a method for providing a user agent with serviceidentification data according to an embodiment of the disclosure.

FIG. 3 is a call flow diagram according to an embodiment of thedisclosure.

FIG. 4 is a call flow diagram according to an alternative embodiment ofthe disclosure.

FIG. 5 is a call flow diagram according to an alternative embodiment ofthe disclosure.

FIG. 6 is a call flow diagram according to an alternative embodiment ofthe disclosure.

FIG. 7 is a call flow diagram according to an alternative embodiment ofthe disclosure.

FIG. 8 is a call flow diagram according to an alternative embodiment ofthe disclosure.

FIG. 9 is a diagram of a wireless communications system including a UAoperable for some of the various embodiments of the disclosure.

FIG. 10 is a block diagram of a UA operable for some of the variousembodiments of the disclosure.

FIG. 11 is a diagram of a software environment that may be implementedon a UA operable for some of the various embodiments of the disclosure.

FIG. 12 illustrates an exemplary general-purpose computer systemsuitable for implementing the several embodiments of the presentdisclosure.

DETAILED DESCRIPTION

It should be understood at the outset that although illustrativeimplementations of one or more embodiments of the present disclosure areprovided below, the disclosed systems and/or methods may be implementedusing any number of techniques, whether currently known or in existence.The disclosure should in no way be limited to the illustrativeimplementations, drawings, and techniques illustrated below, includingthe exemplary designs and implementations illustrated and describedherein, but may be modified within the scope of the appended claimsalong with their full scope of equivalents.

In an embodiment, a method for providing a user agent (UA) with serviceidentification data is provided. The method includes an applicationserver (AS) transmitting Session Initiation Protocol (SIP) data (seeIETF RFC 3261). The SIP data comprises an identifier of the AS and aservice identifier for at least one service supported by the AS. Themethod further includes the UA receiving the SIP data.

In an embodiment, a user agent (UA) is provided. The UA includes aprocessor configured to receive Session Initiation Protocol (SIP) data.The SIP data comprises an identifier of an application server (AS) and aservice identifier for at least one service supported by the AS.

In an embodiment, a network component is provided. The network componentincludes a processor configured to transmit Session Initiation Protocol(SIP) data. The SIP data comprises an identifier of the networkcomponent and a service identifier for at least one service supported bythe network component.

The IMS architecture allows UAs to be provided with services such ascall waiting, call forwarding, reception of multimedia content, andother well known services. The services are typically provided byapplication servers or similar components in an IMS network. A servingcall session control function (S-CSCF) or a similar component in the IMSnetwork typically identifies that an incoming message is invoking aparticular service and inserts an application server that can providethat service into the session path.

When two UAs are communicating or attempting to communicate, the type ofexchange that occurs between them when one of them invokes a servicedepends on whether the application server that is providing the serviceis on the originating end of the session, the terminating end of thesession, or both. It might be preferable that an application serverproviding a particular service be available to both the originating UEand the terminating UE (it should be understood that a UE as well as anapplication server as well as some other network element can eachcomprise at least one UA).

In an embodiment, a message that is sent to a UE from an applicationserver (AS) that is providing a particular service includes a serviceidentifier that identifies the application server and the service thatis being provided. The service identifier might be provided to both theoriginating and the terminating UAs, by the same or by different ASes.The service identifier can inform the terminating UA of the servicesthat are available from the servers that are on the route that anincoming message took. The service identifier can also indicate whethera server providing a service is an originating server or a terminatingserver.

FIG. 1 is a block diagram of an embodiment of a system 100 in which suchservice identifiers might be implemented. The system 100 includes a UA₁110 _(a) that is capable of using IMS communication services or similarservices. The UA₁ 110 _(a) can communicate with another UA₂ 110 _(b)that has similar capabilities. If UA₁ 110 _(a) is originating acommunication session request that is to be terminated at UA₂ 110 _(b),UA₁ 110 _(a) might first send a message to an S-CSCF 120. The S-CSCF 120might then determine a service that the requested session is invokingand might insert into the session path an application server (AS) 130that can provide that service. The application server 130 might be atelephony application server ((T)AS) or a similar component. As usedherein, the term “(T)AS” can refer to a telephony application serverspecifically or to an application server or a similar network node ingeneral. The functionality on the application server or network nodeneed not be the same as that is associated with a “(T)AS” and could beany application/service that the service providers want to provide. Theapplication server 130 might connect the other UA₂ 110 _(b) into thesession and provide the invoked service. The application server 130might route the communication session request back to the S-CSCF 120,which might route it in the direction of UA₂ 110 _(b). The communicationsession request might pass other S-CSCFs or the same S-CSCF 120 andother (T)ASes or the (T)AS 130 while on its way to UA₂ 110 _(b). Thecommunication session request may be diverted.

In an embodiment, the application server 130 can include a serviceidentifier 140 in the header of a SIP message 150 that the applicationserver 130 sends to the terminating UA₂ 110 _(b) and/or to theoriginating UA₁ 110 _(a). In some cases, the same SIP message 150 issent to both UA₁ 110 _(a) and UA₂ 110 _(b). In other cases, differentSIP messages 150 are sent to UA₁ 110 _(a) and UA₂ 110 _(b). The headerthat includes the service identifier 140 might be a Record-Route header,a Route header, a Via header, or a similar header or even a new header.Alternatively, the service identifier 140 could be included in a Contactaddress. The service identifier 140 can be used to identify that anapplication server that provides a service is available to the UAs 110and also the address or URI of the application server 130 that providesthe service. The service identifier 140 may satisfy the property that ifthe same (T)AS 130 provides services to both UA₁ 110 _(a) and UA₂ 110_(b), UA₁ 110 _(a) and UA₂ 110 _(b) will each be able to determine thatthe (T)AS 130 is indicating it offers services to UA₁ 110 _(a) or UA₂110 _(b). I.e., if both UA₁ 110 _(a) and UA₂ 110 _(b) share the samepublic identity, the AS 130 may be able indicate that it hasinstantiated a call model or UA or state within the (T)AS 130 to offerservices to UA₁ 110 _(a) and that it has instantiated another call modelor UA or state within the (T)AS 130 to offer services to UA₂ 110 _(b)since both UAs may be subscribed to the same service profile. Forexample, if a service identifier 140 includes a GRUU (or ‘gr’ parameter(with instance-id) according to IETF's Internet Draft“draft-ietf-sip-gruu”) it would have the property of identifying thesame AS as well as uniquely identifying the UA within.

FIG. 2 is a diagram of a method 200 for providing a user agent withservice identification data. At event 210, an application servertransmits Session Initiation Protocol (SIP) data that includes anidentifier of the application server and a service identifier thatidentifies at least one service supported by the application server. Atevent 220, the user agent receives the SIP data.

More specifically, when a (T)AS or other network node acting as a proxyforwards an incoming multimedia telephony-related SIP message (e.g. SIPINVITE request or other initial request), the (T)AS includes its UniformResource Identifier (URI) in the Record-Route header. If the terminatingUA can recognize the URI of the (T)AS in the Record-Route header as thatof the (T)AS, or UA within the (T)AS, serving it, then it can determinethat the (T)AS is in the signaling route and can therefore provide theuser with the capability to invoke the user's (e.g., supplementary)services. Likewise, if the originating UA can recognize the URI of the(T)AS in the Route header in the response as the (T)AS, or UA within the(T)AS, serving it, then it can determine that the (T)AS is in thesignaling route and can therefore provide that user with the capabilityto invoke that user's (e.g. supplementary) services.

Also, the UA can obtain the URI of the AS that it may use to addresscertain SIP requests to perform or request certain service relatedfunctions or features.

According to Third Generation Partnership Project (3GPP) TechnicalSpecification (TS) 24.229 and 3GPP TS 24.173, IMS communication servicescan be identified by means of one or more IMS Communication ServiceIdentifiers (ICSI). The ICSI might be used for policing and chargingpurposes in the home network. A UA may indicate an ICSI in theP-Preferred-Service header. The home network can validate the ICSI andcreate a P-Asserted-Service header with appropriate ICSI values. Thehome network may even assign an ICSI and include a P-Asserted-Serviceheader with an ICSI value if the P-Preferred-Service header is notpresent.

In an embodiment, a URI parameter can be set equal to the ICSI value fora particular service. This URI parameter can be included in a URI that a(T)AS includes in a Record-Route header. When a UA reads this URI, theUA can know that the (T)AS associated with the URI is providing theservice associated with the URI parameter. The g.3ppp.app_ref parametermight be reused for this purpose, or another token could be defined forthis parameter.

In addition, it may be necessary to identify whether the UA that isserved by the particular (T)AS is the terminating UA or the originatingUA. Identifying the terminating or originating UA served by the (T)ASmight be necessary because it is possible that there will be (T)ASs forboth the originating UA and the terminating UA and each needs toidentify its own (T)AS. Each might also need to identify a (T)AS thatserves it when there is only a single (T)AS on the signaling route (suchas in a non-IMS to IMS scenario). Identifying the terminating ororiginating UA that the (T)AS serves can be achieved by including aparameter, or parameter with values, such as “orig” or “term” in theuser portion of the SIP URI in the Record-Route header.

As an example, the (T)AS serving the originating UA could include in theRecord-Route header the following URI:

Record-Route:  <sip:orig@TAS.networkA.net;g.3gpp.app_ref=urn%3Aurn-  xxx%3A3gpp-service.ims.icsi.mmtel>and the (T)AS serving the terminating UA could include in theRecord-Route header the following URI:

Record-Route:  <sip:term@TAS.networkB.net;g.3gpp.app_ref=urn%3Aurn-  xxx%3A3gpp-service.ims.icsi.mmtel>

If the (T)AS acts as a back-to-back UA (B2BUA), it may or may notinclude a Record-Route header. However, if it acts as a true UA, it willtypically include its own URI in the Contact Header. In this case, the(T)AS might include its URI as above containing the g.3ppp.app_refparameter along with “orig” or “term” in the user portion.

When the terminating UA receives a SIP INVITE or other initial request,it scans the list of Record-Route headers and the Contact header. If itfinds a URI containing the g.3ppp.app_ref parameter “term” in the userpart of the URI, it knows that a (T)AS has been assigned by the (home)network to provide (e.g., supplementary) services for the user. The UAcan then use this information to provide the capability for the user toinvoke (e.g., supplementary) services.

Likewise, the originating UA scans the list of Route headers and theContact header in the 200OK response to find out if a (T)AS has beenassigned to provide (e.g., supplementary) services for its user basedupon finding a URI containing the g.3ppp.app_ref parameter “orig” in theuser part of the URI.

When constructing a REGISTER request, UAs may include feature tagscontaining ICSI values in the Contact header, as described in InternetEngineering Task Force (IETF) Request for Comments (RFC) 3840. Eitherthrough registration or administratively, such ICSI values may cause anySIP requests (e.g., INVITE requests) that include one or more matchingICSI values in the Accept-Contact header to be routed to the UAs thatregistered the contact addresses, according to the mechanism in IETF RFC3841 and algorithms in IETF RFC 2533.

The value representing IMS Multimedia Telephony Communication Serviceswill be referred to herein as MMTel ICSI. IMS Multimedia TelephonyCommunication Services are a subset of IMS Communication Services, andIMS Communication Services are a subset of SIP communication services.The present disclosure is not restricted to IMS Multimedia TelephonyCommunication Services or IMS Communication Services. As used herein,the terms “IMS Communication Services” and the like can be consideredsynonymous with the terms “SIP communication services” and the like, andthe term “ICSI” can be considered synonymous with more general termssuch as “SIP communication service identifier” or “SipCSI”.

It should be noted that an MMTel application is a capability, not apreference. An appropriate way for an inviting UA to represent thismight be to include the MMTel ICSI in the g.3ppp.app_ref media featuretag in the Contact header. In the case where a UA indicates multipleICSI values in the g.3ppp.app_ref media feature tag in the Contactheader, the MMTel application can ensure that the MMTel ICSI value isthe first value in the list of values. This provides a hint that the UAsupports and is using the MMTel application.

It has been suggested that inclusion of the MMTel ICSI value in theContact header could make a UA aware that an IMS Multimedia TelephonyCommunication Service has been established by signaling this informationvia the Accept-Contact header. However, the use of the Accept-Contactheader for such purposes may not be appropriate based on its currentlyagreed semantic in IETF RFC 3841. The present disclosure discusses howto signal that an intermediate SIP Server performing services on behalfof a UA has been inserted in the signaling route in order to providesuch information to the terminating UA.

Several issues may arise when a server is inserted in the signalingroute. On the originating side, when the use of IMS Multimedia TelephonyCommunication Services entails the inclusion of one or more (T)ASsand/or other (SIP) application servers, it may be desirable to indicatethat the session being requested includes in the signaling path one ormore application servers performing communication service logic. Theindication might be provided to the terminating user's UA, theterminating user's proxy, and/or to the terminating user's IMSMultimedia Telephony Communication Services platform.

In addition, the originating user's S-CSCF and/or the terminating user'sS-CSCF may use the ICSI values to include (T)ASs and/or otherapplication servers in the path. The terminating users proxy may use theindication of the ICSI values to resolve the terminating user's UA'scapability of supporting one or more of the IMS Communication Servicescorresponding to the ICSI values. The terminating user's UA may use theICSI values to select the appropriate logic in the UA that is capable ofhandling the IMS Communication Services corresponding to the applicationserver-asserted ICSI values. Asserted indications may be used by theoperator during its charging operations and to validate that the userhas the appropriate subscriptions. The network may indicate failure ofthe request by, for example, returning a SIP 420 (Bad Extension)response if the proxies in the path do not support one or more of theIMS Communication Services corresponding to the ICSI values. A UA maywish to publish its support for certain IMS Communication Servicescorresponding to the ICSI values. This information could be stored inthe address books of recipients and used when indicating a preferencefor reaching a UA that also understands the ICSI values.

The terminating UA may wish to execute IMS Multimedia TelephonyCommunication Services independent of whether or which IMS MultimediaTelephony Communication Services are executed by the originating UA.Receipt of an ICSI in the Accept-Contact header on the terminating sidedoes not necessarily indicate that the suitable (T)ASs are in thesignaling path or even that the originating UA is currently invoking thecorresponding Communication Service.

In an embodiment, the Record-Route header or Via header or Route headeror a yet to be defined new header (in the case of a SIP proxy or AS inthe role of a proxy) or the Contact address (in the case of a SIP B2BUAor AS in the role of a B2BUA) could include an indication that anapplication server hosting an IMS Multimedia Telephony CommunicationService is included in the signaling route. The indication might bereferred to herein as a service identifier or a token. The token mightalternatively be referred to as an identifier, an alphanumeric string, afeature tag, a fully qualified domain name, or some other term. Thepresence of the token could be interpreted as proof that some or all ofthe user's associated Multimedia Telephony Communication Services are inthe session path.

The token might need to be unique per UA and public user identifier(PUID), since a UA may request a session to be set up with another UAwith the same PUID (e.g., a husband calls a wife who shares his PUID).The token typically should uniquely identify a particular IMS MultimediaTelephony Communication Service for a particular Contact address. TheContact address can be used to publish that a UA supports some IMSMultimedia Telephony Communication Services. A UA can use thisinformation to map the request to the corresponding logic and the (T)AScan use the token to map to the corresponding state machine. A tokenmight uniquely identify a relation between an IMS Communication Service(originating or terminating), a subscriber, a user, and/or a uniqueidentifier for a UA (e.g., a globally routable UA URI (GRUU)). The tokenmight also assert to the UA that application servers capable of handlingthe ICSI indicated by the token in the Record-Route header are insertedin the session path. A SIP message (e.g., a SIP 420 (Bad Extension)response) may be returned if the terminating UA, proxy, or terminatingnetwork does not support the ICSI indicated.

In one possible implementation, an S-CSCF informs interested applicationservers about a registration, using the procedures defined in clause 6.3of 3GPP TS 23.218. The application servers may, in addition, subscribeto the S-CSCF Reg Event package. This provides a mechanism for anapplication server to discover all the implicitly registered PUIDswithout requiring multiple REGISTER requests to be sent to theapplication server. This also allows the application server to obtainthe current capabilities of a UA as well as to be notified about refreshregistrations and de-registrations. The S-CSCF might send NOTIFYrequests to the application server that has subscribed to the Reg Eventpackage for the registered PUID. The Reg Event package also provides amechanism for the application server to obtain the associated parameters(e.g., GRUUs, ICSIs, and IARIs) for each contact of every registeredpublic identity. This is shown in FIG. 3. The final step in FIG. 3,“Optionally populate unique tokens”, suggests that the (T)AS 130 orother application servers may wish to provision unique tokens oralgorithms in the UA 110, one unique value per ICSI and UA 110 or perICSI and PUID. Steps 3 to 6 are illustrative; in other embodiments othersteps may be performed to obtain the information.

FIG. 4 shows an originating UA₁ 110 _(a) initiating a session. In thisfigure, it is assumed that three UAs (UA₁ 110 _(a), UA₂ 110 _(b), andUA₃ 110 c) have all registered the same PUID (Public User Identity),have all third-party registered with the same (T)AS 130 and are all ableto identify their unique value per the ICSI that they support. At step 3and step 5, the (T)AS 130 can insert in the Record-Route header, Contactheader, or some other header a token that is recognized by all UAs 110registering with the same PUID and might initiate a state machineidentified by that token. Because multiple UAs 110 have registered withthe same PUID and forking may happen downstream, the (T)AS 130 mightdecide in this case to include a token that can be recognized by all UAs110 registered under the same PUID for that particular IMS CommunicationService identified by an ICSI. Before steps 7-13, the originating UA₁110 _(a) may have internally offered the INVITE to the logic supportingthe SIP communication service identified by the token recognized by theUA 110. In turn, upon receipt of a SIP message with a token, (e.g., inthe SIP responses to the INVITE messages in steps 7-13) the (T)AS 130can hand the SIP message off to the state machines identified by thetoken.

Session border control elements (e.g., the 3GPP IMS Interconnect BorderControl Function) should not strip the unique tokens. If they do, the UA110 cannot be sure that an IMS Communication Service indicated by atoken is supported by the network during the session.

A token or service identifier might need to possess certain propertiesin order to identify an ICSI. Certain structures might be needed tosatisfy these properties, and certain ways might be needed for the UA tobe able to recognize the token (e.g., according to step 7 in FIG. 3).One property is that the token might need to identify to the user that aserver supporting the IMS communication service identified by the tokenis included on the route of SIP signaling for a session. An examplemight besip:<publicuseridentity>@<icsi>.originatingleg.<operatorname>.net, where<icsi> could map to MMTel, <operatorname> could map to an operator namesuch as Verizon or Sprint, “originatingleg” (or alternatively, “orig”)identifies this leg of the session as an originating leg, and<publicuseridentity> could map to the user portion of the user's publicuser identity URI, such as “john.doe”. Also, the token might need tosecurely identify to the user that the IMS Communication Serviceidentified by the token is in the session path. This may include therequirement that all other elements in the network (excluding UAs havingregistered the same PUID) perceive the token as an opaque value that isnot to be removed from a SIP message (e.g.,sip:foo2@foo1.terminatingleg.<operatorname>.com). The token might alsoneed to identify to the application server which state machine belongsto the session. If multiple UAs registering with the same PUID aresupported, and if one UA is allowed to call its own PUID, the tokenshould be recognizable by all UAs registering with the same PUID. Thetoken may also include an indication whether the application serverinserting the token executes the IMS Communication Service on behalf ofthe originating UA or the terminating UA.

A UA should be able to recognize the token and should be able to map thetoken to a SIP communication service it supports. If the UA does notrecognize the token, the UA may still be able to map the request to aSIP communication service it supports. For the UA to recognize itstokens, it should know what to look for, and the application serversinserting the tokens should know what the UA expects. In some cases, theUA and the application servers might agree on the tokens when the UAregisters, for example by exchanging them. The UA could determine andshare a token per SIP communication service, or the application serverscould determine and share a token per SIP communication service.Alternatively, the tokens could be hard coded. If users with differentPUIDs register, different tokens might be exchanged. In devices that usesubscriber identity modules (SIMs), storage of the tokens might need tobe resistant to the swapping of SIMs. Alternatively, an algorithm thatis either hard coded or downloadable could allow the UA to identify thetokens and relate them with the corresponding SIP communicationservices. In any of these cases, device management (DM), short messageservice (SMS), unstructured supplementary service data (USSD), etc., canbe used to inform the UA or the application server of mutuallyunderstood tokens that map to ICSIs. Alternatively, it may be possibleto derive a token from a GRUU, an International Mobile EquipmentIdentity (IMEI), or an address of record (AOR).

FIG. 5 illustrates an alternative embodiment. In this case, when the UAregisters with the IMS network, a home subscriber server (HSS) mightdownload a profile of data over the Cx interface into the S-CSCF. One ofthe parameters of the profile might be a list of URLs (the list can have0 to X entries) that identifies the location(s) where the configurationdata for the subscriber is stored. The UA's registration with thenetwork and the third-party registration might be performed usingInitial Filter Criteria (iFC). One example might be that, when the SIPREGISTER arrives, the iFC could have additional triggers that indicatethat if a token, such as an ICSI, is received in the SIP Contact header,then a third-party registration shall be sent to a network node, such asan application server, that supports the token.

Once the third-party registration has finished, the network node mightthen need to subscribe to the Reg Event package to obtain all the PUIDsand their corresponding GRUUs for that subscriber. The network nodemight also receive a message body according to some Content Type or aContent Type per IETF RFC 4483 describing the location where theconfiguration data is to be stored. Once the network node has this, thenetwork node creates the configuration data and uploads it to theconfiguration node database per the URL received from the content typein the NOTIFY. If there are many network nodes that have received athird-party registration, all these network nodes could upload thisconfiguration data to this database. The database could be available toall network nodes, could be in one network node, or all network nodescould have their own unique location to update the data.

As part of the SIP registration, the UA may subscribe to the Reg Eventpackage, which delivers information back to the UA. The message thatcomes back (an example being SIP NOTIFY) can contain a Content type perIETF RFC 4483 that contains the location(s) of the configurationinformation needed by the UA that was downloaded from the HSS asdescribed above. This information can be retrieved from the URL(s) asspecified in the Content type or message body, can be stored in eitherremovable or other types of memory, internal or otherwise, such as thoselisted below, and can be used for the initial session establishments bythe UA for originated, terminated, or session continuity operations.

The following is an example of a SIP SUBSCRIBE message that could beused in this embodiment:

SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 From:<sip:user_aor_1@example.net>;tag=27182 To: <sip:user_aor_1@example.net>Call-Id: gbjg0b@ua.example.com CSeq: 45001 SUBSCRIBE Route:<sip:proxy.example.net;lr> Event: reg Expires: 3600 Accept:application/reginfo+xml Contact:<sip:user_aor_1@example.net;gr=hha9s8d-999a> Content-Length: 0

The memory types can include are but not limited to internal memory,CompactFlash, Type I, CompactFlash, Type II, SmartMedia, MMC, MMCplus,RS-MMC, MMCmobile, MMCmicro, Memory Stick Standard, Pro, Memory StickDuo, Pro Duo, Memory Stick Micro, SD, miniSD, microSD, xD, USB, andother currently known or after developed memory device.

FIG. 6 illustrates another alternative embodiment. In thisimplementation, the Config Node is the S-CSCF or can be another node. Inthis case, the 200 (OK) response is not immediately sent back to the UAwhen the registration procedure is finished. The S-CSCF holds the 200(OK) response for a period of time specified by a timer (not shown)and/or until a body to be included in the SIP 200 (OK) response has beenpopulated or until the config node has been populated. If needed, therunning of the timer allows the application servers to populate theConfig Node function and then send back the 200 (OK) response with thelocation of the data and the Config Node.

FIG. 7 illustrates another alternative embodiment. This implementationis similar to the implementation of FIG. 5, except that in this case theConfig Node is co-located with the S-CSCF so that the URL provided tothe S-CSCF from the HSS points to the S-CSCF. Thus, each applicationserver will populate the relevant page on the S-CSCF with itssemi-dynamic configuration data for the UA. This could includedownloading XCAP/XML information.

FIG. 8 illustrates another alternative embodiment. This alternativerepresents the reverse case, where the UA uploads the tokens and/oralgorithms to the network using the REGISTER request it transmits (or anSMS or XCAP method). The UA could put a 3GPP XML IM CN body (part) oranother body (part) with the tokens and their mappings in the SIPREGISTER request's body, or it could put a URL in the request. It couldthen be assumed that the S-CSCF either directly forwards thisinformation to the application servers in question or enables retrievalof this information. The application server could then download from theURL provided by the UA (pointing to a web browser on the UA or pointingto a web page/server elsewhere in the network that makes these tokensavailable). With registration, if a depository is referenced, a certaintime might need to be given to the UA to make the deposit, so a timervalue could be sent in the XML. The application server can receive thetimer value and know that it should act after the timer value hasexpired.

The following Open Mobile Alliance (OMA) Device Management (DM)techniques can be used to statically or dynamically provision SipCSIsand their tokens or algorithms. A token_identity_List interior node canbe used to allow a reference to a list of SIP communication services(e.g., hosted on application servers) that can provide a certain serviceto the device. The Occurrence might be One, the Format might be node,the Access Types might be Get, and the Values might be N/A. A run-timetokens_List node can act as a placeholder for one or more tokens. TheOccurrence might be OneOrMore, the Format might be node, the AccessTypes might be Get, and the Values might be N/A. A Public_user_identityleaf can represent one or more public user identities. The Occurrencemight be One, the Format might be chr, the Access Types might be Get,and the Values might be <token>. An example of a token might be sip:username@domain.com, where “username” is an element that identifies theuser and “domain.com” identifies the application server, as well aswhether it is the originating user's session leg or the terminatinguser's session leg.

<Node>  <NodeName>token_identity_List</NodeName>  <!-- Thetoken_identity_List node starts here. -->  <DFProperties>   <AccessType>   <Get/>   </AccessType>   <DFFormat>    <node/>   </DFFormat>  <Occurrence>    <One/>   </Occurrence>   <Scope>    <Permanent/>  </Scope>   <DFTitle>A collection of token identity objects.</DFTitle>  <DFType>    <DDFName/>   </DFType>  </DFProperties>  <Node>  <NodeName/>   <DFProperties>    <AccessType>     <Get/>   </AccessType>    <DFFormat>     <node/>    </DFFormat>   <Occurrence>     <OneOrMore/>    </Occurrence>    <Scope>    <Dynamic/>    </Scope>    <DFTitle>The “name” node for tokenidentity object.</DFTitle>    <DFType>     <DDFName/>    </DFType>  </DFProperties>   <Node>    <NodeName>token_identity</NodeName>   <DFProperties>     <AccessType>      <Get/>     </AccessType>    <DFFormat>      <chr/>     </DFFormat>     <Occurrence>      <One/>    </Occurrence>     <Scope>      <Permanent/>     </Scope>    <DFTitle>token value.</DFTitle>     <DFType>     <MIME>text/plain</MIME>     </DFType>    </DFProperties>   </Node> </Node> </Node>

FIG. 9 illustrates a wireless communications system including anembodiment of the UA 110. The UA 110 is operable for implementingaspects of the disclosure, but the disclosure should not be limited tothese implementations. Though illustrated as a mobile phone, the UA 110may take various forms including a wireless handset, a pager, a personaldigital assistant (PDA), a portable computer, a tablet computer, or alaptop computer. Many suitable devices combine some or all of thesefunctions. In some embodiments of the disclosure, the UA 110 is not ageneral purpose computing device like a portable, laptop or tabletcomputer, but rather is a special-purpose communications device such asa mobile phone, wireless handset, pager, or PDA. In another embodiment,the UA 110 may be a portable, laptop or other computing device. The UA110 may support specialized activities such as gaming, inventorycontrol, job control, and/or task management functions, and so on.

The UA 110 includes a display 402. The UA 110 also includes atouch-sensitive surface, a keyboard or other input keys generallyreferred as 404 for input by a user. The keyboard may be a full orreduced alphanumeric keyboard such as QWERTY, Dvorak, AZERTY, andsequential types, or a traditional numeric keypad with alphabet lettersassociated with a telephone keypad. The input keys may include atrackwheel, an exit or escape key, a trackball, and other navigationalor functional keys, which may be inwardly depressed to provide furtherinput function. The UA 110 may present options for the user to select,controls for the user to actuate, and/or cursors or other indicators forthe user to direct. The UA 110 may further accept data entry from theuser, including numbers to dial or various parameter values forconfiguring the operation of the UA 110. The UA 110 may further executeone or more software or firmware applications in response to usercommands. These applications may configure the UA 110 to perform variouscustomized functions in response to user interaction. Additionally, theUA 110 may be programmed and/or configured over-the-air, for examplefrom a wireless base station, a wireless access point, or a peer UA 110.

Among the various applications executable by the UA 110 are a webbrowser, which enables the display 402 to show a web page. The web pagemay be obtained via wireless communications with a wireless networkaccess node, a cell tower, a peer UA 110, or any other wirelesscommunication network or system 400. The network 400 is coupled to awired network 408, such as the Internet. Via the wireless link and thewired network, the UA 110 has access to information on various servers,such as a server 410. The server 410 may provide content that may beshown on the display 402. Alternately, the UA 110 may access the network400 through a peer UA 110 acting as an intermediary, in a relay type orhop type of connection.

FIG. 10 shows a block diagram of the UA 110. While a variety of knowncomponents of UAs 110 are depicted, in an embodiment a subset of thelisted components and/or additional components not listed may beincluded in the UA 110. The UA 110 includes a digital signal processor(DSP) 502 and a memory 504. As shown, the UA 110 may further include anantenna and front end unit 506, a radio frequency (RF) transceiver 508,an analog baseband processing unit 510, a microphone 512, an earpiecespeaker 514, a headset port 516, an input/output interface 518, aremovable memory card 520, a universal serial bus (USB) port 522, ashort range wireless communication sub-system 524, an alert 526, akeypad 528, a liquid crystal display (LCD), which may include a touchsensitive surface 530, an LCD controller 532, a charge-coupled device(CCD) camera 534, a camera controller 536, and a global positioningsystem (GPS) sensor 538. In an embodiment, the UA 110 may includeanother kind of display that does not provide a touch sensitive screen.In an embodiment, the DSP 502 may communicate directly with the memory504 without passing through the input/output interface 518.

The DSP 502 or some other form of controller or central processing unitoperates to control the various components of the UA 110 in accordancewith embedded software or firmware stored in memory 504 or stored inmemory contained within the DSP 502 itself. In addition to the embeddedsoftware or firmware, the DSP 502 may execute other applications storedin the memory 504 or made available via information carrier media suchas portable data storage media like the removable memory card 520 or viawired or wireless network communications. The application software maycomprise a compiled set of machine-readable instructions that configurethe DSP 502 to provide the desired functionality, or the applicationsoftware may be high-level software instructions to be processed by aninterpreter or compiler to indirectly configure the DSP 502.

The antenna and front end unit 506 may be provided to convert betweenwireless signals and electrical signals, enabling the UA 110 to send andreceive information from a cellular network or some other availablewireless communications network or from a peer UA 110. In an embodiment,the antenna and front end unit 506 may include multiple antennas tosupport beam forming and/or multiple input multiple output (MIMO)operations. As is known to those skilled in the art, MIMO operations mayprovide spatial diversity which can be used to overcome difficultchannel conditions and/or increase channel throughput. The antenna andfront end unit 506 may include antenna tuning and/or impedance matchingcomponents, RF power amplifiers, and/or low noise amplifiers.

The RF transceiver 508 provides frequency shifting, converting receivedRF signals to baseband and converting baseband transmit signals to RF.In some descriptions a radio transceiver or RF transceiver may beunderstood to include other signal processing functionality such asmodulation/demodulation, coding/decoding, interleaving/deinterleaving,spreading/despreading, inverse fast Fourier transforming (IFFT)/fastFourier transforming (FFT), cyclic prefix appending/removal, and othersignal processing functions. For the purposes of clarity, thedescription here separates the description of this signal processingfrom the RF and/or radio stage and conceptually allocates that signalprocessing to the analog baseband processing unit 510 and/or the DSP 502or other central processing unit. In some embodiments, the RFTransceiver 508, portions of the Antenna and Front End 506, and theanalog baseband processing unit 510 may be combined in one or moreprocessing units and/or application specific integrated circuits(ASICs).

The analog baseband processing unit 510 may provide various analogprocessing of inputs and outputs, for example analog processing ofinputs from the microphone 512 and the headset 516 and outputs to theearpiece 514 and the headset 516. To that end, the analog basebandprocessing unit 510 may have ports for connecting to the built-inmicrophone 512 and the earpiece speaker 514 that enable the UA 110 to beused as a cell phone. The analog baseband processing unit 510 mayfurther include a port for connecting to a headset or other hands-freemicrophone and speaker configuration. The analog baseband processingunit 510 may provide digital-to-analog conversion in one signaldirection and analog-to-digital conversion in the opposing signaldirection. In some embodiments, at least some of the functionality ofthe analog baseband processing unit 510 may be provided by digitalprocessing components, for example by the DSP 502 or by other centralprocessing units.

The DSP 502 may perform modulation/demodulation, coding/decoding,interleaving/deinterleaving, spreading/despreading, inverse fast Fouriertransforming (IFFT)/fast Fourier transforming (FFT), cyclic prefixappending/removal, and other signal processing functions associated withwireless communications. In an embodiment, for example in a codedivision multiple access (CDMA) technology application, for atransmitter function the DSP 502 may perform modulation, coding,interleaving, and spreading, and for a receiver function the DSP 502 mayperform despreading, deinterleaving, decoding, and demodulation. Inanother embodiment, for example in an orthogonal frequency divisionmultiplex access (OFDMA) technology application, for the transmitterfunction the DSP 502 may perform modulation, coding, interleaving,inverse fast Fourier transforming, and cyclic prefix appending, and fora receiver function the DSP 502 may perform cyclic prefix removal, fastFourier transforming, deinterleaving, decoding, and demodulation. Inother wireless technology applications, yet other signal processingfunctions and combinations of signal processing functions may beperformed by the DSP 502.

The DSP 502 may communicate with a wireless network via the analogbaseband processing unit 510. In some embodiments, the communication mayprovide Internet connectivity, enabling a user to gain access to contenton the Internet and to send and receive e-mail or text messages. Theinput/output interface 518 interconnects the DSP 502 and variousmemories and interfaces. The memory 504 and the removable memory card520 may provide software and data to configure the operation of the DSP502. Among the interfaces may be the USB interface 522 and the shortrange wireless communication sub-system 524. The USB interface 522 maybe used to charge the UA 110 and may also enable the UA 110 to functionas a peripheral device to exchange information with a personal computeror other computer system. The short range wireless communicationsub-system 524 may include an infrared port, a Bluetooth interface, anIEEE 802.11 compliant wireless interface, or any other short rangewireless communication sub-system, which may enable the UA 110 tocommunicate wirelessly with other nearby UAs and/or wireless basestations.

The input/output interface 518 may further connect the DSP 502 to thealert 526 that, when triggered, causes the UA 110 to provide a notice tothe user, for example, by ringing, playing a melody, or vibrating. Thealert 526 may serve as a mechanism for alerting the user to any ofvarious events such as an incoming call, a new text message, and anappointment reminder by silently vibrating, or by playing a specificpre-assigned melody for a particular caller.

The keypad 528 couples to the DSP 502 via the interface 518 to provideone mechanism for the user to make selections, enter information, andotherwise provide input to the UA 110. The keyboard 528 may be a full orreduced alphanumeric keyboard such as QWERTY, Dvorak, AZERTY andsequential types, or a traditional numeric keypad with alphabet lettersassociated with a telephone keypad. The input keys may include atrackwheel, an exit or escape key, a trackball, and other navigationalor functional keys, which may be inwardly depressed to provide furtherinput function. Another input mechanism may be the LCD 530, which mayinclude touch screen capability and also display text and/or graphics tothe user. The LCD controller 532 couples the DSP 502 to the LCD 530.

The CCD camera 534, if equipped, enables the UA 110 to take digitalpictures. The DSP 502 communicates with the CCD camera 534 via thecamera controller 536. In another embodiment, a camera operatingaccording to a technology other than Charge Coupled Device cameras maybe employed. The GPS sensor 538 is coupled to the DSP 502 to decodeglobal positioning system signals, thereby enabling the UA 110 todetermine its position. Various other peripherals may also be includedto provide additional functions, e.g., radio and television reception.

FIG. 11 illustrates a software environment 602 that may be implementedby the DSP 502. The DSP 502 executes operating system drivers 604 thatprovide a platform from which the rest of the software operates. Theoperating system drivers 604 provide drivers for the node hardware withstandardized interfaces that are accessible to application software. Theoperating system drivers 604 include application management services(“AMS”) 606 that transfer control between applications running on the UA110. Also shown in FIG. 11 are a web browser application 608, a mediaplayer application 610, and Java applets 612. The web browserapplication 608 configures the UA 110 to operate as a web browser,allowing a user to enter information into forms and select links toretrieve and view web pages. The media player application 610 configuresthe UA 110 to retrieve and play audio or audiovisual media. The Javaapplets 612 configure the UA 110 to provide games, utilities, and otherfunctionality. A component 614 might provide functionality describedherein.

The UA 110 and other components described above might include aprocessing component that is capable of executing instructions relatedto the actions described above. FIG. 12 illustrates an example of asystem 1300 that includes a processing component 1310 suitable forimplementing one or more embodiments disclosed herein. In addition tothe processor 1310 (which may be referred to as a central processor unitor CPU), the system 1300 might include network connectivity devices1320, random access memory (RAM) 1330, read only memory (ROM) 1340,secondary storage 1350, and input/output (I/O) devices 1360. In somecases, some of these components may not be present or may be combined invarious combinations with one another or with other components notshown. These components might be located in a single physical entity orin more than one physical entity. Any actions described herein as beingtaken by the processor 1310 might be taken by the processor 1310 aloneor by the processor 1310 in conjunction with one or more componentsshown or not shown in the drawing.

The processor 1310 executes instructions, codes, computer programs, orscripts that it might access from the network connectivity devices 1320,RAM 1330, ROM 1340, or secondary storage 1350 (which might includevarious disk-based systems such as hard disk, floppy disk, or opticaldisk). While only one processor 1310 is shown, multiple processors maybe present. Thus, while instructions may be discussed as being executedby a processor, the instructions may be executed simultaneously,serially, or otherwise by one or multiple processors. The processor 1310may be implemented as one or more CPU chips.

The network connectivity devices 1320 may take the form of modems, modembanks, Ethernet devices, universal serial bus (USB) interface devices,serial interfaces, token ring devices, fiber distributed data interface(FDDI) devices, wireless local area network (WLAN) devices, radiotransceiver devices such as code division multiple access (CDMA) and/orglobal system for mobile communications (GSM) radio transceiver devices,and other well-known devices for connecting to networks. These networkconnectivity devices 1320 may enable the processor 1310 to communicatewith the Internet or one or more telecommunications networks or othernetworks from which the processor 1310 might receive information or towhich the processor 1310 might output information.

The network connectivity devices 1320 might also include one or moretransceiver components 1325 capable of transmitting and/or receivingdata wirelessly in the form of electromagnetic waves, such as radiofrequency signals or microwave frequency signals. Alternatively, thedata may propagate in or on the surface of electrical conductors, incoaxial cables, in waveguides, in optical media such as optical fiber,or in other media. The transceiver component 1325 might include separatereceiving and transmitting units or a single transceiver. Informationtransmitted or received by the transceiver 1325 may include data thathas been processed by the processor 1310 or instructions that are to beexecuted by processor 1310. Such information may be received from andoutputted to a network in the form, for example, of a computer databaseband signal or signal embodied in a carrier wave. The data may beordered according to different sequences as may be desirable for eitherprocessing or generating the data or transmitting or receiving the data.The baseband signal, the signal embedded in the carrier wave, or othertypes of signals currently used or hereafter developed may be referredto as the transmission medium and may be generated according to severalmethods well known to one skilled in the art.

The RAM 1330 might be used to store volatile data and perhaps to storeinstructions that are executed by the processor 1310. The ROM 1340 is anon-volatile memory device that typically has a smaller memory capacitythan the memory capacity of the secondary storage 1350. ROM 1340 mightbe used to store instructions and perhaps data that are read duringexecution of the instructions. Access to both RAM 1330 and ROM 1340 istypically faster than to secondary storage 1350. The secondary storage1350 is typically comprised of one or more disk drives or tape drivesand might be used for non-volatile storage of data or as an over-flowdata storage device if RAM 1330 is not large enough to hold all workingdata. Secondary storage 1350 may be used to store programs that areloaded into RAM 1330 when such programs are selected for execution.

The I/O devices 1360 may include liquid crystal displays (LCDs), touchscreen displays, keyboards, keypads, switches, dials, mice, track balls,voice recognizers, card readers, paper tape readers, printers, videomonitors, or other well-known input devices. Also, the transceiver 1325might be considered to be a component of the I/O devices 1360 instead ofor in addition to being a component of the network connectivity devices1320. Some or all of the I/O devices 1360 may be substantially similarto various components depicted in the previously described drawing ofthe UA 110, such as the display 402 and the input 404.

The following Internet Engineering Task Force (IETF) Requests forComments (RFC) are incorporated herein by reference: RFC 2533, RFC 3840,RFC 3841, and RFC 4483. The following 3rd Generation Partnership Project(3GPP) Technical Specifications (TS) are incorporated herein byreference: TS 23.218, TS 24.229, and TS 24.173. In order to implementthe embodiments described herein, the following changes might be made toTS 24.173: addition of text defining usage of the g.3ppp.app_ref as aURI Parameter; addition of text specifying that the telephonyapplication server includes the g.3ppp.app_ref URI Parameter and “Orig”or “Term” in the user part of the URI that is included in the either theRecord-Route header or the Contact header; and addition of text thatstates that when multiple ICSI values are included in the g.3ppp.app_refmedia feature tag in the Contact header, the MMTel ICSI value should bethe first in the list.

While several embodiments have been provided in the present disclosure,it should be understood that the disclosed systems and methods may beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component, whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and could be made without departing from the spirit and scopedisclosed herein.

1. A method for providing a user agent (UA) with service identificationdata, comprising: an application server (AS) transmitting SessionInitiation Protocol (SIP) data comprising: an identifier of the AS, anda service identifier for at least one service supported by the AS; andthe UA receiving the SIP data.
 2. The method of claim 1 wherein theidentifier of the AS is a uniform resource identifier (URI).
 3. Themethod of claim 2 wherein the URI is Globally Routable UA URI (GRUU). 4.The method of claim 2 wherein the URI contains a ‘gr’ parameter.
 5. Themethod of claim 2 wherein the service identifier is an IP (InternetProtocol) Multimedia Subsystem (IMS) Communication Service Identifier(ICSI).
 6. The method of claim 5 wherein a URI parameter in the URI isset equal to the ICSI.
 7. The method of claim 6 wherein the URIparameter is a g.3ppp.app_ref tag.
 8. The method of claim 2 wherein theURI is included in one of: a Record-Route header; a Record header; a Viaheader; and a Contact address.
 9. The method of claim 8 wherein the URIis included in a SIP INVITE message.
 10. The method of claim 9 wherein auser portion of the URI identifies at least one of: a UA that originatedthe SIP INVITE message; and a UA that terminates the SIP INVITE message.11. The method of claim 1 wherein the service identifier is associatedwith the at least one service by one of: an agreement between the UA andthe AS; a hard coding of the association; and execution of an algorithmthat performs the association.
 12. A user agent (UA) comprising: aprocessor configured to receive Session Initiation Protocol (SIP) datacomprising: an identifier of an application server (AS); and a serviceidentifier for at least one service supported by the AS.
 13. The UA ofclaim 12 wherein the identifier of the AS is a uniform resourceidentifier (URI).
 14. The UA of claim 13 wherein the URI is GloballyRoutable UA URI (GRUU).
 15. The UA of claim 13 wherein the URI containsa ‘gr’ parameter.
 16. The UA of claim 13 wherein the service identifieris an IP (Internet Protocol) Multimedia Subsystem (IMS) CommunicationService Identifier (ICSI).
 17. The UA of claim 16 wherein a URIparameter in the URI is set equal to the ICSI.
 18. The UA of claim 17wherein the URI parameter is a g.3ppp.app_ref tag.
 19. The UA of claim13 wherein the URI is included in one of: a Record-Route header; aRecord header; a Via header; and a Contact address.
 20. The UA of claim19 wherein the URI is included in a SIP INVITE message.
 21. The UA ofclaim 20 wherein a user portion of the URI identifies at least one of: aUA that originated the SIP INVITE message; and a UA that terminates theSIP INVITE message.
 22. The UA of claim 12 wherein the serviceidentifier is associated with the at least one service by one of: anagreement between the UA and the AS; a hard coding of the association;and execution of an algorithm that performs the association.
 23. Anetwork component comprising: a processor configured to transmit SessionInitiation Protocol (SIP) data comprising: an identifier of the networkcomponent; and a service identifier for at least one service supportedby the network component.
 24. The network component of claim 23 whereinthe identifier of the network component is a uniform resource identifier(URI).
 25. The UA of claim 24 wherein the URI is Globally Routable UAURI (GRUU).
 26. The UA of claim 24 wherein the URI contains a ‘gr’parameter.
 27. The network component of claim 24 wherein the serviceidentifier is an IP (Internet Protocol) Multimedia Subsystem (IMS)Communication Service Identifier (ICSI).
 28. The network component ofclaim 27 wherein a URI parameter in the URI is set equal to the ICSI.29. The network component of claim 28 wherein the URI parameter is ag.3ppp.app_ref tag.
 30. The network component of claim 24 wherein theURI is included in one of: a Record-Route header; a Record header; a Viaheader; and a Contact address.
 31. The network component of claim 30wherein the URI is included in a SIP INVITE message.
 32. The networkcomponent of claim 31 wherein a user portion of the URI identifies atleast one of: a user agent that originated the SIP INVITE message; and auser agent that terminates the SIP INVITE message.
 33. The networkcomponent of claim 23 wherein the service identifier is associated withthe at least one service by one of: an agreement between a user agentand the network component; a hard coding of the association; andexecution of an algorithm that performs the association.
 34. The networkcomponent of claim 23 wherein the network component is one of: anapplication server; and a telephony application server.